本章重點

• 權限不是愛的供養，是最低可行的工具。
• 金鑰不怕外流，怕的是不會過期與不能撤銷。
• 權限是收緊再開例外，不是先放再補破網。

貝老闆：「好消息！我把 GCP、Replit、第三方服務的金鑰都丟到 google drive 專案資料夾，大家都有所有權限，新人一拉專案就能跑，超快！」

小可：「超快外流啦! 你又忘記 Day 8 的教訓嗎 ……你連 production 的也放進去幹嘛？！大家都有 admin 權限！？」

AI 實習生：「所以我可以看 google drive 所有 API Key 嗎？」

工程師 King：「剛上線的 billing 還沒限權，任何人都能查到金流紀錄。這不是 CI/CD，是 CSI。」

貝老闆：「欸？我放在 google drive 沒放在 github 上啊?」

小可：「重點是有些東西不能給 AI 實習生看啊。快打給好威。」

好威：「上次都說過了，這次要跟你收錢了，三件事先刻到牆上：最小必要權限、角色導向存取、金鑰短期有效且自動輪替。金鑰不是紅包，不能大家有份。」

好威解析

1. Least Privilege（最小必要權限）：每個人、每支程式、每個環境都只拿到完成任務的最低權限。新人的目標是能跑 dev，不是打開全宇宙大門。
2. RBAC（角色導向存取控制）：不要對「人」直接給權限，先定義角色，例如 Dev-Frontend、Dev-Backend、Ops-Admin、Intern-ReadOnly，再把人加到角色。換人、外包、實習結束才不會滿地拆炸彈。
3. Secret Rotation（金鑰輪替）：長期金鑰一定會外流（總有一天）。把它改成短期 Token，並設定逾期自動輪替，就算外流也只能活幾十分鐘。

概念拆解

1）Vault 與分環境金鑰管理：1Password／Secrets Manager
如果不熟悉 Cloud 的 Valut ，小公司實務上可以用 1Password 建三個 Vault：Dev、Staging、Prod，把金鑰、連線字串、Webhook Secret 分開存。只有 Ops-Admin 能管 Prod，Developers 只能讀 Dev。協作時用 1Password Service Account 或手動分享「一次性密碼」讓 CI/CD 拉取，而不是把 .env 寫進 Git。若走雲端內建，GCP 用 Secret Manager 存放，搭配 IAM 只讓指定的 Service Account 在指定專案讀取；所有密文都要加上 命名慣例（如 prod/payments/stripe_secret），方便審計與回收。

2）GCP IAM 階層與自訂角色
不要一股腦給 Editor。用 GCP 的組織階層（Org → Folder → Project）把金流、用戶資料與實驗環境分在不同 Project。建立 自訂角色（Custom Role），例如 sa.reports.reader 只含 BigQuery 的 jobs.create 與特定 Dataset 的 tables.getData，再讓後端服務用 Service Account Impersonation 代入。人員只綁角色、程式只綁 Service Account。審計靠 Cloud Audit Logs，異常告警用 Log‑based Metrics + Alerting。

3）短期 Token 與自動輪替實作
原則是「不用長期金鑰檔」。CI/CD（如 GitHub Actions、Cloud Build 或 Replit 部署流程）用工作負載身分換取短期憑證：在 GCP 以 Service Account Impersonation 取得 1 小時的存取 Token；存於記憶體或 Replit 的 Secrets（只放 dev 用的非敏感值），成功部署後即丟棄。同時設定輪替：

• 應用層：定期重新抓取資料庫密碼／外部 API Token。
• 平台層：用 Cloud Scheduler 觸發 Cloud Run Job 週期重發金鑰、更新 Secret Manager 版本，舊版設為 DESTROY，並通知 Slack。

實作小範例

# 讓 CI 以 Service Account Impersonation 取得短期 Token（示意）
gcloud auth print-access-token \
  --impersonate-service-account=deploy-bot@project.iam.gserviceaccount.com \
  > $RUN_TOKEN
# 之後以 $RUN_TOKEN 呼叫 GCP API，完成後立刻銷毀暫存

# .env.local（僅本機或 dev，用假資料或低權限測試帳號）
NEXT_PUBLIC_API_BASE=https://dev.api.example.com
REPORT_READ_SCOPE=read:demo

Takeaways

A）先畫權限矩陣再開帳號
列出「人 × 環境 × 動作」：例如新人對 Prod 一律 Deny，承包商僅限 Staging 讀取記錄，Ops-Admin 才能管理金鑰。文件放到 README/SECURITY.md，讓 AI 實習生也能照表操課。以後有人說「我需要看一下 production DB」時，先對照矩陣再決定是否開例外單。

B）所有密鑰皆可撤銷，皆會過期
凡是不能撤銷或沒有到期日的金鑰，一律視為風險。設定 Secret Manager 的版本化，輪替時新增版本、移除舊版存取，並寫自動化腳本廣播到 Slack：誰在用、何時到期、替換指引。這讓外流變成「小事 30 分鐘自癒」，而不是「大事全公司通宵」。

C）把 Replit 當入口，不當保險箱
Replit 的 Secrets 很適合 dev 快速跑起來，但 prod 密鑰請放在雲端 Secret Manager 由 CI 拉取。讓 AI 實習生只拿到假資料或低權限 Token；真的需要壓測或串接第三方時，走一次性臨時憑證並全程記錄。快可以快，安全不能省。

今日提問

• 你們團隊目前誰能看到 Prod 的金鑰？這張名單最後一次審查是什麼時候？
• 你有沒有一鍵撤銷與一鍵輪替的腳本？在半夜被叫醒時，它能救你嗎？

小作業 · 給 AI 的 Prompt

請幫我依照以下規則，產生我們專案的權限矩陣（CSV 與 Markdown 兩份）：
1）角色：Dev-Frontend、Dev-Backend、Ops-Admin、Intern-ReadOnly。
2）環境：Dev、Staging、Prod。
3）系統：GCP Secret Manager、BigQuery、Cloud Run、Stripe。
4）原則：最小必要權限、預設 Deny，需附理由與到期日欄位。